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ABSTRACT 


A Shuttle mission planned in 1991 will test the feasibility of tethers in 
space. This mission, a joint effort between Italy and the United States, will 
connect a satellite (built by the Italians) to the Shuttle with a 20 km long 
tether . 

This mission poses unique navigation problems. The flight software on the 
Shuttle was never designed to account for the low level acceleration that is 
generated by the gravity gradient. IMUs on the Shuttle will sense the 
acceleration of the tether but it turns out that incorporating the continuous 
accelerometer noise also generates large error growth. Relative navigation is 
another important issue since the majority of the mission will be conducted 
while the satellite is out of the visual range of the crew. Some kind of 
feedback on the motion of the satellite will be desirable. Feedback of the 
satellite motion can be generated by using the rendezvous radar. To process 
the radar measurements, the flight software uses a 13 state Kalman Filter, but 
unforunately with the filter currently tuned as it is, valid measurements tend 
to be ignored. This is due to the constraint of the tether on the satellite, 
which is an unmodeled force. Analysis shows that with proper tuning, relative 
navigation is possible. 
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1 . 0 INTRODUCTION 


The first tether satellite mission (TSS1) is an attempt to fly the easiest 
profile that can be performed and yet provide us with valuable data to proceed 
with more complex tethered missions. Several questions and issues need to be 
resolved: Can the onboard flight software propagate the inertial state 
accurately enough? Can the ground software update the state? Can the Shuttle 
maintain a good target state? Additionally, there are numerous proximity 
issues that will also need to be answered. This paper will describe the 
analysis and answer the questions that pertain to the current onboard flight 
software, and in particular, to relative navigation issues. 

The basic design of this mission is to fly the Shuttle at an altitude of 296 
km. A satellite, built by Aeritalia, will be deployed away from the Earth 
(upward deploy) on a 20 km. long tether. The satellite is a 1 . 5 m diameter 
sphere containing various instrumentation. The tether consists of kevlar with 
a conducting wire passing through it. The mission does call for a 1 amp 
current to be passed along the tether. 

Satellite thrusters will be used during the deploy until the gravity gradient 
between the Shuttle and the satellite is sufficient to continue deploying at 
the desired rate. During the deploy, the satellite will fall behind the z 
radial of the Shuttle and during the retrieval, it will be in front of the z 
radial. This can be seen pictorially in Figure 7. 

There are two basic programs used to perform this analysis. The tether 
mission trajectories are generated using Shuttle Tethered Object Control 
Simulation (STOCS) . STOCS is a high fidelity Shuttle simulation with a 
general purpose tether model attached. Reference 1 describes STOCS in greater 
detail. Onboard software is modeled in Shuttle Environment and Navigation 
Software for Onorbit and Rendezvous (SENSOR). Section 2.1 gives more 

explanation of the onboard software and Reference 2 gives a full description 
Of SENSOR . 
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2.0 DISCUSSION 


The satellite, a small object, will be out of visual range of the crew for the 
majority of the mission. Sensors mounted on the boom indicate, among other 
things, tether tension, tether angle and length of tether deployed, but this 
information does not give a lot of direct feedback on the satellite itself. 
More useful information could be obtained by using the rendezvous radar, which 
generates range, range rate and in and out of plane angles of the satellite. 
This radar data is also information that the crew has seen before and is 
familiar with. 

The radar is self contained and handles tracking by itself so the simplest 
method of use would be to turn it on and watch the data. What happens if the 
radar breaks lock? Remember that the satellite is small and will be up to 20 
km from the radar. Since the default search mode of the radar is to start the 
search with a shaft and trunnion angle of 0" and a range of 609 m, it i3 
unlikely that the radar will be able to reacquire the target. An alternative 
would be to use the Relative Navigation (Rel Nav) function on the Shuttle. 
Using Rel Nav allows the flight software to maintain a target state. When the 
radar tries to acquire a target, the navigation software (Nav) will supply a 
target state vector. As will be seen later, there are also problems using the 
radar with Rel Nav. 


2 . 1 FLIGHT SOFTWARE BASICS 

There are two methods for incorporating accelerations into the state 
propagations. The first is by using modeled atmospheric drag and modeled vent 
and thrusting. An alternative method is by using the Inertial Measuring Unit 
(IMU) sensed acceleration output. The appropriate acceleration source is 
chosen by comparing the IMU sensed accelerations against the 1,000 )ig 
threshold. If the sensed accelerations are less then this threshold, then the 
models are used, otherwise the IMU output is used. Sensed accelerations will 
also be used if the digital autopilot (DAP) jet flag is turned on during a 
given Nav cycle. The DAP jet flag is used to incorporate jet firing when it 
is known that the low level accelerations are due to the jet firing. Finally, 
a 4 x 4 gravity model is used for the state propagation which is performed by 
the Super G integrator. 
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Relative navigation data processing is done using a thirteen state Kalman 
Filter. The first three components of the state are the inertial position and 
velocity vectors. States seven through nine are the inertial unmodeled 
acceleration biases, which are used in the calculation of the vehicle 
accelerations. Finally, the last four states are the measurement biases. The 

flight software has a choice of filtering the Shuttle state or the target 
state. 


2.2 PROCESSING K TETHER MISSION 

The first step to onboard processing is to propagate the inertial position and 
velocity of the vehicles. For the Shuttle, the immediate consequence of 
having the tether attached is to impart a continuous low level acceleration. 
Unfortunately, the tether acceleration is below 1,000 Hg. Setting the 
acceleration limit lower so that the state propagation could pick up the 
tether acceleration does not work since IMU errors are also incorporated. 

This leads to worse state propagation than when the tether is ignored. Ruling 
out flight software modifications, the inertial error growth will have to be 
accepted and handled through ground processing with state vector uplinks. 

The next step to onboard processing is to address the relative navigation 
problem. Typically, the Shuttle state is the choice state for filtering. The 
reason is that normally the target has been tracked for months and it's orbit 
13 well known. Also, the target will be essentially dead and therefore will 
not be venting or thrusting. Modeled accelerations are sufficiently accurate 
in propagating the target state for these types of rendezvous. The Shuttle, 
on the other hand, is conducting numerous venting and thrusting. Thus, the 
Shuttle state is better suited for filtering during a nominal rendezvous. For 
the tether mission, the Shuttle is still performing the venting and thrusting, 
but look at what the target is doing. It will be moving from an orbit at 296 
km to an orbit at 316 km. Thus, the target state is better suited for 
filtering during the tether mission. 

During the propagation/update process, the filter takes the measurements and 
adjusts the state by using the measurement residual and the Kalman gain. When 
the measurements are coming in, one would expect the filter to bring the state 
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closer to the truth. As shown in Figure l f this does not happen. 


o 



o - NRV 


Figure 1 - RELATIVE MOTION FOR STVHO 
USING STANDARD I -LOADS 


If measurements were not being used, the satellite would follow a path shown 
in Figure 2, which depicts the natural motion of the satellite had the tether 
not been connected. This seems to indicate that Nav is using the dynamics in 
the state propagation and is ignoring the measurements. What is actually 
happening can be seen in Figure 3 and Figure 4. The measurements aren’t being 
edited but rather the filter is adjusting the shaft bias by about 80* and the 
trunnion bias by 25*. Successful relative navigation now requires tuning the 
filter and giving the measurements more weight so that they are "believed” 
over the coded dynamics . 
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Figure 4 - RADAR TRUNNION BIAS 


2.3 FILTER TUNING 

The flight software is designed so that various parameters (called I-LOADs) 
can be changed without major recoding of the software. As an example, the 
choice of which vehicle state to filter is set by the I-LOAD 

Shuttle_f ilter_f lag . Eight of these I-LOADs were found to require adjustments 
in order to properly tune the filter. The eight I-LOADs are shown in table 1. 
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TABLE 1 


I-LOADS USED TO TUNE THE FILTER 


I -LOAD NAMF. 
UNMOD_ACC_B I AS_FLAG 

SIG_UPDATE 

VAR_RRDOT 
VAR_RR_ANGLES 
COV_U_A_COAS T 

B I AS_VAR_RRDOT 
B I AS_VAR_RR_ANGLE S 

VAR U A COAST 


DESCRIPTION 

Enable the filter to solve for unmodeled 
acceleration 

change initial position and velocity a to 
prox ops values 

decrease initial range variance 
decrease initial radar angle variance 
increase initial unmodeled acceleration 
variance 

decrease range ecrv bias a for state noise 
decrease radar angle ecrv bias O for state 
noise 

increase unmodeled acceleration ecrv bias 
a for state 


SIG_UPDATE IS used to initialize the covariance. Normally it is only used at 
the beginning of a rendezvous, but for the tether mission, uplinks are 
required which triggers a covariance reinitialization. COV_U_A_COAST will 
also be used at each uplink to reinitialize the unmodeled acceleration slots 
of the covariance matrix. Measurement variances are only used at rendezvous 
start up time and when an instrument is switched. The bias slots of the state 
(slots 7 - 13) are modeled as exponentially correlated random variables 

(ecrv) . The last three parameters in table 1 control the ecrv state noise for 
the propagation. 


2 . 4 RADAR BREAK-LOCK 

A major impact to using relative Navigation during this mission will be if the 
radar loses the lock on the target. Having Rel Nav active will aid in the 
radar finding the target by telling the radar where to look, but in the period 
of time that no measurements are being processed, Nav is simply propagating 
the target state. The target state vector would then be following a path 
similar to that shown in Figure 2. Eventually Nav will be telling the radar 
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to point in the wrong direction. The question for the break-lock: studies is 
how long will it take before Nav points the radar such that it can’t locate 
the target? To answer this, some radar basics are needed. 

When the radar is in GPC mode, it takes a state vector from Nav and points to 
that location. If a positive return signal is not received, a spiralling 
search within a designated cone is begun. The limit of the cone is determined 
by the expected distance to the target. For instance, a cone of ±20* is 
searched at 20 km and a cone of ±30’ is searched at 13 km. A new search is 
begun every 20 seconds until the target is found. 

This topic is studied from a navigation standpoint only. There are other 
concerns about the actual functioning of the radar hardware. One concern is 
that the radar may begin tracking the tether instead of the satellite. This 
can easily be checked real time by watching the radar data and comparing it to 
the timeline and the tether length output. If this phenomenon does happen, it 
will be during the portions of the mission when the satellite is towards the 
20 km point and the tether begins to bow. At some point during the retrieval, 
the radar should be able to reacquire the satellite via Rel Nav and target 
state vector uplinks. Reacquiring the target during retrieval will still be a 
useful aid to the mission and crew by having some radar feedback as the 
satellite approaches the Shuttle. 
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3.0 MISSION ANALYSIS 


Several different trajectories were generated and processed for the TSS1 
mission. The purpose of having the different trajectories is to try to 
encompass the actual performance (a true unknown) within simulated data. To 
do this, various scenarios were generated by adjusting mission parameters. By 
doing this, the most difficult mission to navigate was found to be one that 
needed a lot of attitude controlling. This mission profile also required 
numerous uplinks to keep the Shuttle inertial state errors within procedural 
limits . 

The particular trajectory used in this paper is named STVHO. The profile uses 
vernier jet control and there is a current flowing through the tether during 
the on-station phase of the mission. The Shuttle is held at a pitch of 25‘ 
nose up with 2* attitude dead bands. Six uplinks were required for this 
profile . 


There is a concern as to what happens to a standard rendezvous when I-LOADs 
are changed. This could be a question if another rendezvous is scheduled for 
the same Shuttle mission or if an unplanned rendezvous would be desired. To 
look at this, I used a trajectory called OMP13, which is simulated data. A 30 
cycle Monte Carlo run was performed on both STVHO and OMP13. 


3.1 ANALYSIS OF STVHO 

Figures 5 and 6 show the 30 cycle Monte Carlo output for STVHO. These two 
plots indicate good Rel Nav performance. The downtrack and cross track errors 
both 320 m during the on-station phase and reducing to zero towards the 
end of the retrieval. The radial position error remains around 20 m 
throughout the whole mission. Velocity errors seen in Figure 6 also are 
acceptable. The spikes, which are more prominent in the velocity plot, are 
due to the state vector uplinks. When an uplink occurs, the covariance gets 
reset and it takes about 1,000 seconds for the filter to recover. 
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Figure 5 - RELATIVE POSITION ERROR FOR STVHO 



o - Y LVLH ERROR 
a - Z LVLH ERROR 


Figure 6 * RELATIVE VELOCITY ERROR FOR STVHO 



Figure 7 shows the Shuttle centered relative motion plot for STVHO. 

Differences seen in the trace of the environment versus Nav is due to the 
measurement errors so the actual mission could vary depending on how well the 
measurement errors have been predicted. With the measurement errors used, the 
angle between the line of site error to the on-station points seen in Figure 7 
is around 1.3*. 


ONSTATION PORTION 



o - ENV 
c - NRV 


Figure 7 - RELATIVE MOTION PLOT FOR STVHO 


3.2 ANALYSIS OF OMP13 USING THE NEW I -LOADS 

Figures 8 and 9 show 0MP13 using the standard filter I-LOADs. Star tracker 
measurements are taken during the first portion of the rendezvous . At 10,000 
seconds the measurement source is switched to the rendezvous radar. These 
plots show typical performance. Figure 10 is the target centered relative 
motion plot. Figures 11, 12 and 13 are for OMP13 using the new I-LOAD set. 
Performance is the same up until 12,000 seconds. This is the point of the 
profile where the Terminal phase Initiation (TI) burn is executed. 
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a - Z LVLH ERROR 

Figure 8 - RELATIVE POSITION ERROR FOR OMP13 WITH 
THE STANDARD I-LOADS 



a - z LVLH ERROR 

Figure 9 - RELATIVE VELOCITY ERROR FOR OMP13 WITH 
STANDARD I-LOADS 
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Another significant event during this time is angle measurements drop out from 
12,000 seconds to 14,000 seconds . The relative motion data in Figure 13 does 
not reflect the state errors shown in Figure 11 because Figure 13 is from a 
single cycle run. The Monte Carlo analysis in SENSOR does not print the 
relative state for each cycle. 

The performance of OMP13 with the new I-LOAD set is not good. The Root- 
Sum^Squared (RSS) position error at 14,000 seconds into the run is 7,000 m. 

The actual distance between the Shuttle and the target at this time is 
approximately 12,000 m. This portion of the rendezvous requires several 
midcourse maneuvers, which are normally targeted onboard. The plots show that 
the Nav state would not be accurate enough to do this. 


3.3 RADAR BREAK-LOCK ANALYSIS 

This analysis was performed by inhibiting measurements at a given time. This 
allowed Nav to propagate the target state using normal orbital dynamics. 
Figures 14, 15 and 16 show results at three different times: 1,000 seconds, 
15,000 seconds and 45,000 seconds respectively. Relative times can be taken 
from the plots since there is 38.4 seconds between markers. 

The objective is to see how long Nav can propagate the state before the state 
error is to large to help the radar point at the target. The lines shown on 
the plots indicate the point after which the target will not be within the 
search cone of a given Nav state. The work shown here attempts to answer the 
break-lock question from a navigation stand point. The actual radar hardware 
could shorten the period of time for reacquisition. 

Figure 14 shows an interesting propagation, which is due to the unusual motion 
of the satellite at the time the measurements are shut off. This plot 
indicates that it will take 800 seconds before the Nav state will point the 
radar in the correct direction to find the target. From this point, there is 
700 seconds for which the Nav state will point the radar such that it can 
reacquire the target. 
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The next run, shown in Figure 15, behaves as expected. If the break-lock 
happens 15,000 seconds into the deploy, the radar has 450 seconds to reacquire 



the target before Nav state errors become to large. This time is based only 
on the search cone. There is also a large range difference betneen the Nav 
state and the actual position of the target which could also limit the 
reacquisition time. 


Figure 16 shows the final case analyzed. This break-lock is simulated at 
45,000 seconds into the run, which is during the on-station phase of the 
mission. This plot indicates that about 400 seconds are available for Nav to 
help the radar find the target. Again, as previously mentioned, there is a 
large range difference between the environment and the Nav state. 
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Figure 14 


- RADAR BREAK-LOCK AT 1000 SECONDS 


LVLH Z POS (M) 



Figure 15 - RADAR BREAK-LOCK AT 15,000 SECONDS 
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Figure 16 - RADAR BREAK-LOCK AT 45,000 SECONDS 


4.0 CONCLUSIONS 


Relative navigation performance is acceptable for the TSS1 mission. To do 
this requires 9 I-LOADs to be changed. This new I-LOAD set does work for the 
standard rendezvous trajectory that I have available, but shows poor 
performance during the final 14 km of the rendezvous. State vector uplinks 
around the time of the TI burn might be able to keep the state errors within 
acceptable limits. An alternative method of performing a standard rendezvous 
would be to target the midcourse maneuvers on the ground and then uplink them 
to the Shuttle. These ideas require more analysis. 

The performance of the radar itself is a question that may not be completely 
answered until the mission. The satellite is small and will be difficult to 
track at 20 km. If tracking of the satellite is not possible at the extreme 
distances, Rel Nav and the radar, with the help of ground uplinks, should be 
able to acquire the target at some point during the retrieval. 
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